Jan Wagner: Running Ghost blogging platform via Docker
When I was thinking about using Ghost, I did read the installations guide and then I just closed the browser window. I didn't wanted to install npm, yet another package manager, and just hack init scripts. Not speaking about updating Ghost itself. Some weeks later I did think about using Ghost again. It has a nice Markdown Editor and some nice other features. Since everybody is jumping on the Docker band wagon actually and I had used it for some tests already, I thought trying the Ghost Docker image might be a good idea. If you are interested into how I did that, read on. I suppose you have installed a stock Debian Jessie.
Installing Docker
Pulling the Docker image
Just in case you didn't, you need to (re)start docker to work with service docker restart
# docker pull ghost
Making Ghost (container image) run forever
I did not like systemd in the first place for many reasons. But in some circumstances it makes sense. In case of handling a Docker container, using a systemd unit file makes life much easier.
# mkdir -p /srv/docker/ghost/
# cat > /etc/systemd/system/ghost.service << EOF
[Unit]
Description=GHost Service
After=docker.service
Requires=docker.service
[Service]
ExecStartPre=-/usr/bin/docker kill ghost
ExecStartPre=-/usr/bin/docker rm ghost
ExecStartPre=-/usr/bin/docker pull ghost
ExecStart=/usr/bin/docker run --name ghost --publish 2368:2368 --env 'NODE_ENV=production' --volume /srv/docker/ghost/:/var/lib/ghost ghost
ExecStop=/usr/bin/docker stop ghost
[Install]
WantedBy=multi-user.target
EOF
# systemctl enable ghost && systemctl daemon-reload && systemctl start ghost
This will start your container on start and even is looking for a new Docker image and is fetching it, if needed. If you don't like this behavior, just comment out the line in the config and reread it with systemctl daemon-reload.
Now you should have listening something on port 2368:
# netstat -tapn grep 2368
tcp6 0 0 :::2368 :::* LISTEN 7061/docker-proxy
Update: Jo l Dinel did send me a mail, that starting your Docker container with --restart always will take care that it is brought up again if Docker or (even) the whole system will get restarted. For real I used that before and might be a lightweight solution, but I liked the systemd unit file solution a lot more.
Persistent Data
Thanks to the Docker mount option you can find all your data in /srv/docker/ghost/. So your blog will still have content, even if the ghost Docker images is updated:
# ls /srv/docker/ghost/
apps config.js data images themes
Accessing the container
To kick your ghost into production, it might be useful if you make it available on port 80 at least. This can be done for example by changing your Docker publish configuration or adding a DNAT to your firewall.
But I would recommand using a proxy in front of your Docker container. This might be part of one of my next articles.
docker to work with service docker restart
# docker pull ghost
Making Ghost (container image) run forever
I did not like systemd in the first place for many reasons. But in some circumstances it makes sense. In case of handling a Docker container, using a systemd unit file makes life much easier.
# mkdir -p /srv/docker/ghost/
# cat > /etc/systemd/system/ghost.service << EOF
[Unit]
Description=GHost Service
After=docker.service
Requires=docker.service
[Service]
ExecStartPre=-/usr/bin/docker kill ghost
ExecStartPre=-/usr/bin/docker rm ghost
ExecStartPre=-/usr/bin/docker pull ghost
ExecStart=/usr/bin/docker run --name ghost --publish 2368:2368 --env 'NODE_ENV=production' --volume /srv/docker/ghost/:/var/lib/ghost ghost
ExecStop=/usr/bin/docker stop ghost
[Install]
WantedBy=multi-user.target
EOF
# systemctl enable ghost && systemctl daemon-reload && systemctl start ghost
This will start your container on start and even is looking for a new Docker image and is fetching it, if needed. If you don't like this behavior, just comment out the line in the config and reread it with systemctl daemon-reload.
Now you should have listening something on port 2368:
# netstat -tapn grep 2368
tcp6 0 0 :::2368 :::* LISTEN 7061/docker-proxy
Update: Jo l Dinel did send me a mail, that starting your Docker container with --restart always will take care that it is brought up again if Docker or (even) the whole system will get restarted. For real I used that before and might be a lightweight solution, but I liked the systemd unit file solution a lot more.
Persistent Data
Thanks to the Docker mount option you can find all your data in /srv/docker/ghost/. So your blog will still have content, even if the ghost Docker images is updated:
# ls /srv/docker/ghost/
apps config.js data images themes
Accessing the container
To kick your ghost into production, it might be useful if you make it available on port 80 at least. This can be done for example by changing your Docker publish configuration or adding a DNAT to your firewall.
But I would recommand using a proxy in front of your Docker container. This might be part of one of my next articles.
# mkdir -p /srv/docker/ghost/
# cat > /etc/systemd/system/ghost.service << EOF
[Unit]
Description=GHost Service
After=docker.service
Requires=docker.service
[Service]
ExecStartPre=-/usr/bin/docker kill ghost
ExecStartPre=-/usr/bin/docker rm ghost
ExecStartPre=-/usr/bin/docker pull ghost
ExecStart=/usr/bin/docker run --name ghost --publish 2368:2368 --env 'NODE_ENV=production' --volume /srv/docker/ghost/:/var/lib/ghost ghost
ExecStop=/usr/bin/docker stop ghost
[Install]
WantedBy=multi-user.target
EOF
# systemctl enable ghost && systemctl daemon-reload && systemctl start ghost
# netstat -tapn grep 2368
tcp6 0 0 :::2368 :::* LISTEN 7061/docker-proxy
/srv/docker/ghost/. So your blog will still have content, even if the ghost Docker images is updated:
# ls /srv/docker/ghost/
apps config.js data images themes
.
A good amount of the Debian 
Looking into this with 
The more interesting part is, how to migrate over the clients to the new master in case of a failover process. While Redis Sentinel could also be used as configuration provider, we decided not to use this feature, as the application needs to request the actual master node from Redis Sentinel much often, which will maybe a performance impact.
In case you have spare time at the weekend ahead, it may be worth to spend it with great 
It 
As you can see, the 16 chip design module has printed '9905428-189.A00lf' on and the 8 chip design '9931712-009.A00G'. It's something like in the Wireless LAN USB dongle business where they sell totally different hardware with the same Part Number but different Revisions.
To make it short, both 8 chips design modules worked like a charm, the M471B5773DH0-CH9 and the KVR1333D3S8S9/2G (9931712-009.A00G). - Please avoid the Adolf one from Kingston! ;)
